In second generation (2G) and third generation (3G) wireless networks, mobile terminals (referred to herein as mobile devices) can in principle create regular transport control protocol (TCP)/internet protocol (IP) socket connections to servers on the internet. These connections are treated by the internet as though they are broadly similar to wired connections. However, connections in a wireless network have specific requirements which render them distinct from wired connections. The term “wireless network” used herein includes within its scope conventional cellular networks, and also any kind of network where at least one of the relevant connections is wireless whether cellular or not.
When considering use of the internet, client/server applications are very common and following the ability of mobile devices to create TCP/IP sockets, these kind of applications have become increasingly common in wireless networks as well. To date however, the most usual scenario is that the client is executed on the mobile terminal or device and the server is executed on a computer on the internet. In principle this does not create too much of a difficulty even in a wireless network, because the nature of a client application is normally that it will send a message that demand a response after which it is happy for the connection to remain quiescent until it needs to send another message. Management of connections of this type can be handled using existing mobile device technology.
However, there is a trend in mobile computing to put web servers/web services (or any kind of other services/servers) on the mobile devices themselves and make them accessible to the public internet. In a fixed network environment, the only problem to solve is that of running the server on the mobile device. In a wireless environment however, a TCP/IP connection behaves differently than it does in a fixed network. One reason for this is that network operators optimise and fine tune their network settings, and this often involves connections with very infrequent traffic becoming unreliable. In such as case, the internet end may send a packet and not receive any notification about it having been delivered, and the mobile end may not receive the packet either. At the moment, operators are able to perform such optimisation because the most widespread use of wireless TCP/IP connections consist almost entirely of the mobile end being the client, and therefore the connections being short lived (and managed at the mobile end).
However, when implementing a server or other kind of application on the mobile end which requires to be accessible at all times, there is a need to provide a connectivity solution to avoid the problem that idle connections—that is, connections that have been successfully created and used but over which no traffic has occurred for some period of time, go stale. This staleness may not manifest itself either to the mobile end or the internet end, with the effect that they remain totally unaware that data send over that connection has not reached the other end. Clearly when this happens the system does not work in its intended way.
It is a requirement therefore to minimise the effect of stale connections in a wireless network. This can be done by transmitting keepalive messages from the internet end to the mobile end on a regular basis. However, this has implications. Keeping a connection alive is costly, both in terms of battery consumption at the mobile end and network traffic. Therefore, it is not desirable to transmit keepalive messages too frequently in the case where less infrequent keepalive messages would still maintain the connection open when necessary.
It is a first aim of the present invention to allow for maintenance of a connection using keepalive messages without unnecessarily straining the battery consumption or network traffic requirements.
Another associated problem is that operators use different cellular settings for managing traffic connections. Moreover, the same operator may have different network settings in different cells. It is also possible that some cells simply have broken settings—that is they have a completely different characteristic to other cells. This further complicates the management of the transmission of keepalive messages because, even once set for a particular situation, they may well need to be altered to take into account differing operator settings.
It is therefore a second aim of aspects of the invention to solve this problem.